ciel 3.0.0 with ihp-sg13cmos5l - #140
Conversation
- (breaking) rename family to ihp-sg13 and update ihp build scripts accordingly - fix copyrights on various files - update ci
All of these are breaking changes btw: - outputs to non-ttys are now plain-text instead of JSON - Family.default_includes is now a dictionary of patterns to lists, where the patterns are to be matched against a variant to determine the default library set that should be built/pulled - Families now auto-register to both by_name and a new by_variant class dictionaries - Family.resolve_libraries now requires a new argument, variant - enable, fetch, push, and build now take a (pdk_family, pdk_variant) tuple instead of just the PDK family - enable and fetch no longer support automatic pushing - get_ciel_home now returns a pathlib.Path, and so does Version.get_dir - resolve_pdk_family's argument is no longer optional, moved to family.py, added to top-level exports - resolve_pdk_variant moved to families.py, added to top-level exports - remove deprecated method `get()`
aa9f431 to
d4ea7c8
Compare
adds new variant to ihp-sg13, three new libraries, and a new default include set if installation for that specific variant is requested
be6d03d to
f1c8c78
Compare
f1c8c78 to
9625178
Compare
mole99
left a comment
mole99
left a comment
There was a problem hiding this comment.
Looks good to me!
The pdk-family/pdk-variant tuple makes things much less ambiguous.
| def fetch( | ||
| pdk_root: str, | ||
| pdk: str, | ||
| pdk_tuple: Tuple[str, str], |
There was a problem hiding this comment.
For some semblance of backcompat, maybe
| pdk_tuple: Tuple[str, str], | |
| pdk_selector: Union[str, Tuple[str, str]], |
and then resolve the tuple?
There was a problem hiding this comment.
That would be possible!
Btw. shouldn't it then be Union[str, Tuple[str, List[str]]], since the PDK variants can be multiple?
Since the variable name has changed (pdk -> pdk_tuple), backwards compatibility isn't given anyway if passed by name, right?
So maybe we should focus on tidying up the API, even if that means breakage?
There was a problem hiding this comment.
Ciel is fairly low maintenance effort so I'd say tidying up the API shouldn't be our sole focus
Remember, the primary consumer of Ciel's API is LibreLane so I need to optimize for that use case :)
2 participants
There is a lot. Please check the commits for more info.
Please also do not squash this PR. I spread the changes cleanly for better traceability in the future.